大家有沒有一種經驗就是照三餐開會,到底怎麼那麼多會議要開?
生命以時間為單位,浪費別人的時間是謀財害命,浪費自己的時間則是慢性自殺
魯迅
工作久了,常常需要參加各種會議,而對於工程師來說,會議的目的通常包括以下幾種:
開會前提是為了解決某些需要合作的問題,先不論會議的目的如何,重要的是在開會之前明確定義會議的命題,命題是為了讓參與者了解會議背後的目的和內容。
開會前或後重要的是維持 bounded context,透過正確的命題來讓背後的問題能真正獲得解決
命題的關鍵在於定義並告知為何重要 (Why Impact),避免多個部門之間的協調和確認流程上的決策成本產生,使決策的來源和原因變得明確 (AKA 老闆的意圖)。
說法一: 幫我把這個按鈕加⼤,顏⾊⽤明顯⼀點
說法二: 客⼾反應會員續訂的機率有點低,實際訪談後發現很多⼈沒有注意到按鈕,請問有更好的呈現⽅式嗎?
在會議中,一些常見的問題包括:
要讓別人感覺到你是一個人,不然就只是一直投廣告
溝通是否達陣,關鍵在控制對方要聽到什麼
會議的重點應該是讓大家了解其他人的發言跟自己有什麼關係。
在選擇開會方式時,可以根據不同的情況和目的進行區分:
按照頻率區分
按照場地區分
按人數區分
人多的會議不重要,重要的會議人不多
常見的 Daily Scrum 會有三個制式的問題
雖然 3QF 在 2017 年就改成一個範例,但大家慢慢發現這個輪流回答的格式本身不一定會促進協作。
每個人會機械式等待,並且進行填空問答,若是主管在場目的就會變成裝忙。
個人認為比較好的取代方案是透過像是 slack 的聊天機器人,有問題的時候也可以針對討論串進行回覆。
在 scrum guild 2020 之後這個 3QF 就改成
The Developers can select whatever structure and techniques they want.
週會通常用於同步工作進度和狀態,根據小編的過去經驗,週會的主要目的是確保團隊的工作進展順利。
前公司部門額外需要安排輪值會議紀錄,後來建議主管開會前大家先把想講的提早撰寫於會議紀錄。
有一些輔助開會的工具可供使用,例如使用用戶故事、領域驅動設計(DDD)和統一建模語言(UML)等工具來協助溝通。此外,使用 Trello、看板等工具可以增加會議的透明度。
小編在之前的文章中從提問的目的、問題的分類、針對問題事前準備、提問的步驟、描述問題的技巧來看怎麼問問題,這裡一樣附上幾個例子,目的都是盡量將蒐集過重要的資訊和脈絡講清楚
問法一: 這個功能兩個禮拜後要完成可以嗎?
問法二: 客⼾三週後要跟⻑官報告但系統還有⼀些問題,想確認⽬前⼯作項⽬與優先順序以及是否有時間處理?
問法一: 請問 YAML 是什麼?
問法二: 網路上說 YAML 可以讓 CICD 更方便,但我還是有點不了解應⽤⽅式,可以請你評估看看讓我了解是否適合⽤在這個專案嗎?
問法一: ⽼闆,你要這個嗎?
問法二: 經評估為產⽣ $$$ 效益,⽬前規劃 3 種⽅案,這些⽅案差異在於 OOO、因此目前解決方案是是 XXX 且需要 %%% 部⾨資源,想了解有什麼想法和建議?
問法一: 上次說的購物車功能,開發好了嗎?
問法二: 關於購物車的流程優化的功能,原本預計下週三完成,⽬前還順利嗎?